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A. Additional Definitions 

We presented many parts of System !D and DJS in §3, §4, 
and §5. In this appendix, we consider some details that 
did not fit in that presentation, as well as our treatment of 
break and label expressions to facilitate the desugaring of 
control operators in JavaScript. Then, in Appendix B we 



outline how to extend System !D to support better location 
polymorphism. 

A.l Syntax 

In addition to the expression syntax in Figure 7, System !D 
includes the following forms: 

e ::= ••■ I @x : e \ break @x v 

An expression @x : e labels the enclosed expression, and 
a break expression break @x v terminates execution of 
the innermost expression labeled @x within the function 
currently being evaluated and produces the result v. If no 
such labeled expression is found, evaluation becomes stuck. 
Label and break expressions are included to translate the 
control flow operations of DJS. 

To analyze label and break expressions, the expression 
typing relation uses a label environment VL (in addition to 
type and heap environments), where each binding records 
the world that the expression labeled @x is expected to 
satisfy. 



A.2 Well-Formedness 



Q.,@x:{T IT.) 



The well-formedness relations, defined in Figure 14 



largely straightforward. We use the procedure Binders to 
collect aU of the binders in a world or heap. 

A.3 Subtyping 



[Figure 15] presents more of the subtyping relations. 

Implication. As in System D, subtyping on refinement 
types reduces to implication of refinement formulas, which 
are discharged by a combination of uninterpreted, first-order 
reasoning and syntactic subtyping. If the SMT solver alone 
cannot discharge an implication obligation (I- Valid), the 
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Figure 14. Well-formedness for System !D 



formula is rearranged into conjunctive normal form (I-Cnf), 
and goals of the form w :: J7 are discharged by a combi- 
nation of uninterpreted reasoning and syntactic subtyping 
(I-ImpSyn). 

We write |T]] for the embedding of a type as a formula, a 
straightforward definition f3\ that lifts to environments [F]], 



Subtyping (see Figure 8) 

Syntactic Subtyping (extends Figure 8) 
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Figure 15. Subtyping for System !D 

heap bindings [/i], heaps and worlds IW^. Because 
heap binders may refer to each other in any order (recall 
that a heap can be thought of as a dependent tuple, where 
each component is named with a binder), the embedding of 
a heap starts by inserting dummy bindings so that all binders 
in scope for the type of each heap binding. For example: 

Eo = (Ho, (£1 ^ x:Ti) e {I2 ^ y-T2)) 
lEol = {x: Top], ly: Topi lTil{x), ^iy) 

Syntactic Subtyping. The U-Arrow rule for function 
types is familiar, treating input worlds contravariantly and 
output worlds covariantly. 

Worlds. In order to check world subtyping, the judgement 
r H xi:Ti/{H,hi) g x2-T2/{H,h2) checks that Ti is a 
subtype of T2 and that the heaps agree on the "deep" part 
H. Then, it checks that the structure of the "shallow" parts 
match — using a heap matching relation that uses a = oper- 
ator (not shown) that permutes bindings as necessary — and 



Value Typing 
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Figure 16. Value type checking for System !D 



creates a substitution vr of binders from /i2 to hi. Finally, the 
heap bindings, which can be thought of as dependent tuples, 
are embedded as formulas and checked by implication. 

A.4 Value Typing 

We supplement our discussion of value typing, defined in 
[Figure 16{ from §4. The T-EXTEND rule for dictionaries is 
straightforward. The T-Loc rule assigns run-time location 
r (which appears during evaluation, but not in source pro- 
grams) a reference type corresponding to its compile-time 
location, using the mapping StaticLoc. Notice that, unlike 
the version of the rule from Figure 9, the rule T-FUN uses an 
empty label environment to type check function bodies, so 
that break expressions cannot cross function boundaries. 



Expression Typing T; E; H i- e :: T/E' 

Rules from Figure 10, updated with label environments: 

r;Ei-u::r T; E; ^ I- ei :: Ti /Ei T, 2::ri; Ei; i- 62 r2/E2 

[T-Val] [T-Let] 

T; T.; Qt- V :: T/E T; E; f7 i- let x = a in 62 :: 3x:Ti. T2IT.2 

r;Ei-t;::S' T, irw%(i;); E; 1- ei :: Ti /Ei V Jalsy{v); T.; Q. ^ e2 ■■ T2 IT.2 T/E' = Join(?;, Ti /Ei , T2 /E2) 

1—' t^-lF] 

F; E; SI I- if u then ei else 62 T/E 

iidomCE) F;Ei-u::r E' = E e ^^ u) F; E 1- u :: ije/^ E = Eo 9 1^ 

[T-REF] ; -. ; 7— [T-DEREF] 

F; E; Q \- ref £ v :: Ref£/T,' F; E; S7 i- deref « :: {y\y = v'}/T, 

F; E I- (vi, V2) ■■: (Refe, T) h i dom,{T.) F; E k {vi, V2) :: {Diet, Ref £2) 

^ = -£o®ie<^v) = T,o ® {£ ^ V2) E = T,o® i£2^(v',£3)) T,' = E ® {£1 ^ {V1J2)) 

[T-SETREF] ; ; [T-NEWOBJ] 

F; E; n t- vi := V2 ■■ {x\x = V2} jYl F; E; k newobj £1 «i V2 ■■ Ref£i/E 

r;T,i-vi :: ^[A;L;H] Wi ^ W2 F; E 1- V2 ■■ T2 F 1- [T/A] F H [m/M] F K J_E/If] 
^2 = FreshenCPyz) (VP'i', W2") = Unroll(Hlnst(Llnst(Tlnst((Wi, W2), Ar),IJ),7f, E)) 

Fk T2/E ^ W^i'; TT W^i' = a;:Tii/Eii tt' = 7r[t;2/x-] TrVa" = x':Ti2/Si2 HeapEnv(Ei2) = (y :S, E12) 
— [T-App] 

F; E; fii- [T;£;E]ui V2 ■■ 3x' ■.T12. 3y:S. {z\z = x'} /T.12 

Additional rules: 
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Figure 17. Expression type checking for System !D 



A.5 Expression Typing 

When we presented expression typing in §4.4, we ignored 
break and label expressions, so the typing judgement re- 
ferred only to type and heap environments. To account for 
control operators, the expression typing judgement is of the 
form F; E; f2 1- e :: T/E', where a label environment is an 
additional input. We define the typing rules in [Figure 17| and 
supplement our previous discussion. The T-As and T-SUB 
rules are straightforward. Aside from the rules for label and 
break expressions, label environments il play no interesting 
role. The rules we discussed in §4.4 carry over directly to the 
formulation with label environments. 

Weak Location Bindings. For simplicity, we assume that 
the initial type environment contains all the weak location 
bindings {£ (T, £)) required by the program. 

Thaw and Freeze. To safely allow a weak location £ to 
be treated temporarily as strong. System !D ensures that £ 
has at most one corresponding thawed location at a time; if 



there is none, we say £ is frozen. The rule T-Thaw thaws 
£ to a strong location £ (which we syntactically require be 
distinct from all other thawed locations for £) and updates 
the heap environment with thaw state thwd £ to track the 
correspondence. Subtyping allows null weak references, so 
the output type is null if the original reference is; otherwise, 
it is a reference to £. Finally, the new heap also binds a value 
X of type T, the invariant for all values stored at £, and the 
output type introduces an existential so that x is in scope in 
the new heap. 

The rule T-pREEZE serves two purposes, to merge a 
strong location £ into a weak (frozen) location £ and to re- 
freeze a thawed (strong) location £ that originated from £, 
as long as the heap value stored at £ satisfies the invariant 
required by £. The strong reference is guaranteed to be non- 
null, so the output type remembers that the frozen reference 
is, too. Compared to the presentation in yj, we have com- 



bined freeze and re-freeze into a single freeze expression 
that includes an explicit thaw state 0. 

The result of thawing a weak location is either a strong 
reference or null. Although we could statically require that 
all strong references be non-null before use (to rule out 
the possibility of null-dereference exceptions), we choose to 
allow null references to facilitate idiomatic programming. 
Therefore, we modify the input type for the object primitives 
in objects .dref to allow a null argument. For exam- 
ple, consider the updated input type for hasPropOb j below, 
where T? = {T{v)yv = null}. Notice that we add the pred- 
icate X + null to the output type, because if hasPropObj 
evaluates without raising an exception, then x is guaranteed 
to be non-null. In this way. System !D precisely tracks the 
invariants of thawed objects (cf. passengers from §2.7). 

{x:Ref?, k:Str)/{x>-* {d:Dict,x)) 

{x t null A iff ObjHas{d, k, cur,x))} j same 

Type Instantiation. The TInst procedure processes has- 
type predicates in formulas as follows: 

Tlnst(iu :: A, A, {x \p}) = plw/x] 
Tlnst(m :: B,A,T) = w:: B 



Join. The T-lF rule uses a Join operator, defined in Figure 18 
that combines the type and heap environments along each 
branch (Ti/Ei and T2/^2) such that the type and output 
heap for the overall if-expression (T/ S') are in prenex form. 
The operator starts by using JoinTypes to move existential 
binders for the types to the top-level. Rearranging variables 
in this way is sound because we assume that, by convention, 
all let-bound variables in a program are distinct. Then, we 
use JoinHeaps to combine the bindings in a heap environ- 
ment one location at a time. We show a few representative 
equations in Figure 18] abusing notation in several ways. 



For example, we write h \ £ to denote that i is not bound 
in h. When a location £ is bound in both heaps to values vi 
and V2, respectively, JoinHeaps introduces a new binding 
y whose type is the join of vi and V2- When a location £ 
is bound in only one heap, we use the dummy type Top to 
describe the (non-existent) value in the other heap. There is 
no danger that £ will be unsoundly dereferenced after the if- 
expression, since JoinTypes guards the types of references 
Ref£ with the appropriate guard predicates. 

Conti-ol Operators. The T-Label rule for @x ■ e binds 
the label @a; to an expected world T/ E in the label environ- 
ment used to check e, and expects that all exit points of 
e produce a value and heap environment that satisfy the ex- 
pected world. The exit points are all break @x v expressions 
in e, as well as the "fall-through" of expression e for control 
flow paths that do not end with break; the T-Break rule 
handles the former cases, and the second and third premises 
of T-Label handle the latter. If all exit points satisfy the 
expected world, we use the HeapEnv procedure to convert 



Desugaring (extends Figure 12) 

{( function (x) /* : T * / { e } )) = [DS-Func] 

\{this, arguments). 

let (_xo, • • •) = (ref a^^^ (get arguments "0"), . . .) in 
^return : ((e)) 

(( function F(x) j* : #ctor rx-/{e}))= [DS-Ctor] 

let / = X{this, arguments). 

let (_Xo, . . .) = (ref (get arguments "0"), . . .) in 

©return : ((e)) in 
let p = newobj approto {} (pro(Object)) in 
let d = { "__code__" = / as (( T)); "prototype" = p } in 
newobj ap d (pro(Function)) 

(( return e )) = break ©return ((e)) [DS-Return] 

{{ /* : T * / while (econd) { ebody } )) = [DS-While] 

©break : letrec loop ::T = A(). 

if ((econd)) then ((( ebody )); /oop () ) 
else undefined in loop () 

(( break )) = break ©break undefined [DS-Break] 

(( /* : #thaw £e* / }) = thaw ^ ((e)) [DS-Thaw] 

(( /* : #freeze £ 6 e * / )) = freeze £6 ((e)) [DS-Freeze] 

(( assert(e) )) = ((e)) as {v = true} [DS-Assert] 

Figure 19. Desugaring DJS to System !D 

the heap type into a heap environment, like in the T-APP 
rule. Notice that T-Break derives the type {false} because 
a break immediately completes the evaluation context, thus 
making the subsequent program point unreachable. 

A.6 Desugaring 



In Figure 19 we show more of the desugaring rules. 



Functions and Constructors. As discussed in §5, we 
desugar non-constructor functions (DS-FUNC) to scalar 
function values and constructor functions (DS-Ctor) to ob- 
jects. Following Ajs 101, we wrap each desugared function 
body with the label @return, which facilitates the desug- 
aring of return statements (DS-Return). We desugar 
named, recursive DJS functions via the standard letrec 



encoding using fix; we omit this rule from Figure 19 



DS-Ctor first creates a fresh object at location ap with 
prototype Function . prototype, then stores the desugared 
constructor function in the "__code__" field, and finally cre- 
ates an empty object at location ap r-^to '^hat is stored in the 
"prototype" field, to be used when creating an object with 
this constructor (DS-New). 

Loops. Following Ajg, the DS-While desugars while 
loops to recursive functions (we write letrec as syntac- 
tic sugar for the standard encoding using fix). As such, a 
(function type) annotation describes the invariants that hold 
before and after each iteration. A ©break label around the 
desugared loop body facilitates the desugaring of break 



Join(fe,5'i/Si,5'2/E2) = 3x:T. 3y:T'. S /T. where JoinTypes(6, Si, &) = 3x:T^S 

and JoinHeaps(&,Ei,E2) = {3y:T',T,) 

JoinTypes(6,5i, Sa) = {{b = true => ISij) A (6 = false => [Sa])} 
JoinTypes(6, (3zT:7\. Si),S2) = B^T: (JoinTypes(6, TT, JoinTypes(fe, Si, Sa) 

JoinTypes(6, Si, (3x5:7^. S2)) = 3x^:{Jo\nTypes{b,Top,%)). JoinTypes(6, Si, S2) 
JoinTypes(6, (3^:TT. Si), (3x5:7^. S2)) = 3x1: (JoinTypes(6, tT, I^)). 3xi: (JoinTypes(6, Tbp, T^)). JoinTypes(&, Si, S2) 

JoinHeaps(&, ui) ® fti , ^2) ® /12) = (3y : JoinTypes(6, {x \ x = vi} , {x \ x = V2}) , {(. ^ y) ® JoinHeaps(6, /ii , ^2)) 
JoinHeaps(6, ((. vi) ® hi ,h2\(.) = (3j/: JoinTypes(ti, {x\x = v-i}, Top), 1-^ j/) ® JoinHeaps(fe, /ii, /12)) 
JoinHeaps(6, h\\ I, {(. V2) ® /12) = (3y : JoinTypes(6, Top, {x\x = V2}), {£ 1-^ y) ® JoinHeaps(6, fti, /12)) 

Figure 18. Environment join 



statements (DS-Break). We elide similar mechanisms for 
do-while loops, for loops, f or-in loops, and continue 
statements. 

B. Extensions 

We now outline two ways to increase the expressiveness of 
location polymorphism in System !D. 

B.l Weak Location Polymorpliism 

So far, we have universally quantified function types over 
strong locations. We can make several changes to allow 
quantification over weak locations as well. First, we extend 
the syntax of locations. 



L 



M 



L I L 



We use L to range over weak location variables, and we 
extend the grammar of weak locations £ to include them (in 
addition to weak location constants a). We also define rn 
(resp. M) to range over arbitrary locations (resp. location 
variables). Next, we extend the syntax of function types and 
function application. 



e 
U 



- I [r;m;E]^;i«2 

■■• I V[A;M;7f] */m ^ W2 

ii^(T,£)) I *i®*2 I 



A function type is now parametrized over arbitrary location 
variables AI and a weak heap of bindings that describe 
weak location variables. To match, function application now 
includes location arguments m rather than £; typing must 
ensure that strong location variables L (resp. weak location 
variables L) are instantiated only with strong locations £ 
(resp. weak locations £). 

A function type refers to a weak heap only in the domain 
of the function, because weak locations are flow-insensitive 
and do not vary at different program points. Before, we as- 
sumed that the initial typing environment contained bindings 



for all weak locations. The new syntax of function types re- 
places this convention by abstracting over weak locations. 
Consequently, the function application rule must check that 
the declared weak heap ^ of a function type is satisfiable 
given the cuiTent heap environment S at a call site (after 
substitution of all polymorphic variables). 

B.2 Existential Locations 

Universally quantifying over all locations, including simple 
locations, clutters function types and applications with addi- 
tional arguments, and also exposes locations that are "inter- 
nal" or "local" to the desugared System !D program and not 
accessible in the original DJS program. 

Consider the following example; we refer to the original 
function as / and the desugared version as /'. 



function(x) { 
var y = X 
return y.f }■ 



fun X -> 


let _x = 


ref x 




in 


let _y = 


ref (deref 


_x) 


in 


getElem 


(deref _y, 


"f ") 



We might annotate the DJS function / with the type 

VL,L'. RefL/{L ^ {Dict,L')) 
->■ Top I {L same) 

and the desugared version would have the type 

^L,L',L^,Ly. RefL/(L ^ {Dict,L')) 

Top/{L ^ same) ® (L^r ^ Ref L) e (Ly <-* Ref L) 

that uses additional location variables for the references in- 
serted by the translation. Although it is straightforward to 
mechanically desugar function types in this manner, the ad- 
ditional location parameters at function calls increase the 
manual annotation burden or, more likely since we cannot 
expect DJS programmer to write them, the burden on the 
type system to infer them. 

Instead, we can introduce existential location types into 
the system and write the following type for the desugared 
function /'. 



VL,L'. RefL/{L^{Dict,L')) 

3Lx,Ly. Top/{L M- same) e {Lx Ref L) e {Ly ^ Ref L) 

Notice that the output world uses existentials to name the 
(strong, simple) locations inserted by desugaring. As a re- 
sult, a call to this function need not instantiate the local lo- 
cations; instead, the type system can generate /rei/i location 
constants {i.e., skolemize) for the existential locations. 

We provide a sketch of how to extend System !D with 
existential locations. First, we extend the syntax of types. 

T ::= ■■■ I li.T 

We intend that existential locations only appear in positive 
positions of function types, which we can compute in similar 
fashion to the Poles procedure from System D [3] that tracks 
polarity of types nested within formulas. Effectively, we 
require that every function type be of the form 

^[A-L;H]x:{{y\p})lt^x':{3l. {y'\p'])lt' 

where the input type is a refinement type and the output type 
is in a prenex form that requires all existentially-quantified 
locations to appear at the top-level and which prohibits 
existentially-quantified values. Intuitively, the locations I 
correspond to local reference cells that a function allocates 
when invoked and are inaccessible to callers. 

To introduce existential locations for simple references 
(which are only used by desugaring), we use a new typing 
rule. For technical reasons, we use a let-expression to type 
check reference allocation along with a subsequent expres- 
sion e as a way to describe the scope of i. 

T; El-w :: T r,x:Refl; T, ® {I ^ v); ^ ^ e :: S /T,' 
V; T.; Qh let x = ref I v in e :: 3£. S fT,' 

To facilitate algorithmic type checking, we ensure that exis- 
tential locations are always prenex quantified in types. The 
Join procedure, used for conditionals, rearranges existential 
locations allocated on different branches to maintain this in- 
variant. 

Finally, we need to handle subtyping of existential loca- 
tion types. The simplest approach is to require that two types 
have the same quantifier structure. 

r K Ti != Ta 
r H 3£. Ti c M. Ta 

For first-order functions, we can work around this limitation 
by playing tricks with dummy locations. For higher-order 
functions, however, the presence of existential locations lim- 
its expressivness by constraining the use of the heap. Ab- 
stracting over the mutable state of higher-order functions, 
however, can can be quite heavyweight (see e.g., Hoare Type 
Theory ||5t]); adding more lightweight support in our setting 
is left for future work. 
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